﻿e.Toscana Compliance
Request for Comments:
Del: 6/10/2009
Categoria: Applicativa
Destinatari: Fruitori ed Erogatori del Servizio di Prenotazione Prestazioni Sanitarie
Autori: Rudy Becarelli, Roberto Caldelli (MICC - Media Integration and Communication Centre - Università di Firenze)


RFC Prenotazione DTT-MHP Prestazioni Sanitarie


Abstract
========
Questo documento descrive un servizio di prenotazione su televisione digitale terrestre (DTT) delle prestazioni sanitarie erogate dal Servizio Sanitario Regionale. Il sistema descritto permette di effettuare prenotazioni di prestazioni sanitarie tramite applicazioni Java destinate ad essere eseguite su Set Top Box MHP (Canale Televisivo Digitale Terrestre DTT-MHP).
E' possibile effettuare la prenotazione di una prestazione sanitaria solo previa autenticazione tramite Carta Nazionale dei Servizi (CNS) emessa da Regione Toscana.
Il sistema prevede l'utilizzazione del servizio CS-DTT per la ricezione e lo smistamento dei messaggi provenienti dai Set Top Box relativamente alla funzionalità di prenotazione delle prestazioni sanitarie.
Il servizio CS-DTT viene sfruttato anche per la pubblicazione dell'applicazione MHP presso i broadcaster e per aggiornare i contenuti della stessa in funzione della variazione della tipologia delle prestazioni sanitarie prenotabili direttamente dal cittadino. 


Indice
======
1. Contesto di riferimento
2. Obiettivi
3. Analisi
4. Prototipo
5. Bibliografia


1. Contesto di riferimento
==========================
La rete dei CUP regionali (Centri Unici di Prenotazione) permette di effettuare prenotazioni di prestazioni sanitarie da un unico ufficio presente sul territorio di ogni ASL.
In questo modo l'utente può far riferimento ad un unico punto di accesso per prenotare prestazioni di ogni tipo.
Con il servizio che viene qui presentato si ha intenzione di permettere al singolo utente di effettuare prenotazioni di prestazioni sanitarie, almeno quelle più comuni e facilmente comprensibili all'utente medio, in maniera diretta, sfruttando il canale DTT.


2. Obiettivi
============
La definizione di questo servizio permette essenzialmente due cose:

* Utilizzazione di CART come infrastruttura che permetta un forte disaccoppiamento tra applicazioni di prenotazione e applicazioni di esposizione multicanale delle prenotazioni.
Ogni ASL tipicamente implementa un proprio sistema di prenotazione delle prestazioni sanitarie che gestisce sia la base dati associata, che i sistemi di esposizione delle funzionalità di amministrazione e di prenotazione. Il servizio che viene qui presentato disaccoppia le applicazioni di prenotazione da quelle che permettono l'esposizione multicanale diretta delle prestazioni sanitarie. Tale accorgimento aumenta la modularità del servizio migliorando le sue caratteristiche in termini di flessibilità.

* Possibilità di aggregare i servizi di prenotazione multicanale.
Uno scenario tipico a cui si può far riferimento e che può essere esemplificativo è quello in cui si suppone che esista un sistema centralizzato regionale di prenotazione diretta delle prestazioni sanitarie, mentre ogni singola ASL continua a gestire i propri servizi sanitari territoriali.
La creazione di un centro unificato di prenotazione diretta permette di bilanciare il carico delle prestazioni erogate a livello regionale e di notificare in tempo reale al cittadino quali siano le varie opzioni disponibili sull'intero territorio toscano.
Il centro unificato di prenotazione offre un accesso multicanale comprensivo, per ora, del solo canale DTT-MHP come sopra esposto.


3. Analisi
==========
Il servizio viene esemplificato tramite la consueta schematizzazione CART in cui i SIL sono connessi a NAL che fungono da interfaccia di comunicazione verso l'infrastruttura di cooperazione applicativa. I SIL si connettono ai NAL sfruttando i Web Service esposti dagli Integration Manager ospitati dai NAL stessi.
I SIL che vengono qui presi in considerazione sono:

SIL_SP: SIL del servizio di prenotazione delle prestazioni sanitarie
Tipicamente questi sistemi sono quelli attualmente funzionanti presso ogni ASL. In questo scenario essi hanno anche la capacità di connettersi in Web Service ad un NAL per esporre le loro funzionalità a livello di cooperazione applicativa.

CS-DTT: Centro Servizi DTT di Regione Toscana
Il CS-DTT implementa due distinte funzionalità. La prima permette di reindirizzare le chiamate HTTPS dai Set Top Box, sui quali è in esecuzione l'applicazione di prenotazione delle prestazioni sanitarie, verso i SIL_SP. I SIL_SP prendono in carico la richiesta di prenotazione delle prestazioni e la gestiscono secondo la loro effettiva disponibilità.
La seconda funzionalità permette di pubblicare o aggiornare applicazioni MHP presso un insieme di broadcaster accreditati. Le applicazioni vengono ricevute come archivi (.zip o .rar) allegati ad eventi CART. Tale funzionalità è normata in [1].

CS-DTT-SA: CS-DTT Service Adapter, servizio di adattamento dati verso il canale MHP.
Questo sistema riceve eventi di aggiornamento delle prestazioni sanitarie disponibili alla prenotazione da parte dei vari SIL_SP distribuiti sul territorio regionale. Esso ha il compito di serializzare in maniera opportuna questi dati e di creare un archivio che viene inoltrato via CART a CS-DTT.


3.1 Casi d'uso
==============
Di seguito si presentano due casi d'uso: il primo descrive la modalità con la quale l'Utente Finale effettua una prenotazione via Set Top Box sfruttando l'architettura qui dettagliata; il secondo descrive la modalità con la quale l'applicazione MHP viene pubblicata/aggiornata presso i broadcaster accreditati, tramite il servizio CS-DTT e CS-DTT Service Adapter.

Attori:
-------
SIL_SP
CS-DTT
CS-DTT-SA
UF: Utente Finale

Caso d'uso 1 - Prenotazione di una prestazione sanitaria.
---------------------------------------------------------
Precondizione: L'applicazione MHP di prenotazione viene trasmessa dai broadcaster accreditati con i dati relativi alle prestazioni sanitarie aggiornati ad una certa data.

1. UF manda in esecuzione l'applicazione MHP di prenotazione e navigando attraverso un menu gerarchico seleziona:
- La branca a cui appartiene la prestazione sanitaria richiesta;
- La prestazione desiderata;
- Il presidio preferito e l'unità erogante la stessa;
- La fascia oraria preferita (e.g. 2 per il mattino e 2 per il pomeriggio);

2. Autenticazione di UF tramite CNS;

3. Le informazioni selezionate da UF vengono formattate secondo il punto 4.2 della RFC [1] e vengono inoltrate via HTTPS al CS-DTT.
Secondo tale specifica si dovrà preventivamente registrare presso il CS-DTT l'URL di ogni servizio di prenotazione (SIL_SP) nella forma:

Nome servizio			URL risorsa
-------------			-----------
SIL_SP_numero_servizio		https://"server":"porta"/"sottocartella"/"servlet"

mentre l'URL del proxy di prenotazione del CS-DTT assumerà la forma di:

https://159.213.225.62:8080/CSProxy/csproxy?application=SIL_SP_numero_servizio&params=nome%3Dvnome%26cognome%3Dvcognome%26cf%3Dvcf%26tel%3Dvtel%26prz%3Dvprz%26pre%3Dvpre%26unita%3Dvunita%26fascia%3Dvfascia

ove vengono passati, eventualmente senza l'attribuzione del valore, i seguenti parametri:
- nome
- cognome
- cf (codice fiscale)
- tel (telefono dell'UF)
- prz (codice prestazione sanitaria)
- pre (codice presidio sanitario)
- unita (codice unità)
- fascia (codice fascia oraria)

Per quanto riguarda la fascia oraria, sono previste quattro fascie orarie, due la mattina e due il pomeriggio. Il codice da passare varia da 1 a 4 a partire dalla prima fascia della mattina;

4. CS-DTT inoltra le informazioni ricevute al SIL_SP al quale è destinata la prenotazione. I dati vengono trasmessi in HTTPS;

5. SIL_SP restituisce l'elenco delle disponibiltà effettive sotto forma di documento di testo contenente gli estremi delle prime 5 disponibilità che rispettano i vincoli impostati da UF. Contestualmente queste 5 disponibiltà vengono bloccate fino alla fine del processo descritto.

Il file di testo conterrà informazioni formattate come segue:

N_app=x#app=xxxxxx|data=yyyymmdd|ora=hh:mm|luogo=xxxxxxxxxxx|#...

ove:

- "N_app" rappresenta il numero di disponibilità restituite
- "app" è il codice univoco che individua una certa disponibilità 
- "data" rappresenta la data di erogazione della prestazione
- "ora" rappresenta l'ora di erogazione della prestazione 
- "luogo" rappresenta il luogo di erogazione della prestazione 
- i campi vengono separati dal separatore |
- le disponibilità vengono separate dal separatore #

6. L'applicazione MHP recupera dal file di testo le disponibilità effettive che vengono presentate a UF. UF ne seleziona una;

7. La scelta di UF viene formattata sempre secondo [1] e inviata a CS-DTT che la gira al SIL_SP preposto che la prende in carico, rende nuovamente disponibili le 4 prestazioni non selezionate al servizio di prenotazione, prepara in risposta un messaggio contenente un acknowledgement e alcune eventuali informazioni specifiche riguardanti la prestazione prenotata.
L'URL di selezione di una data disponibilità sarà:

https://159.213.225.62:8080/CSProxy/csproxy?application=SIL_SP_numero_servizio&params=dispo%3Dvdispo

ove vdispo rappresenta il codice app della disponibilità prescelta;

8. SIL_SP conferma a UF la prenotazione e notifica le eventuali informazioni specifiche in un campo note (es. presentarsi digiuni, con certi documenti medici di esami precedenti etc.). Le informazioni vengono inviate sotto forma di file di testo.
Il file conterrà informazioni formattate come segue:

Sgp=xxxxxxxx|data=yyyymmdd|ora=hh:mm|note=xxxxxxxxxxxxx_

Caso d'uso 2 - Pubblicazione/Aggiornamento dell'applicazione MHP.
-----------------------------------------------------------------
Precondizione: Presso CS-DTT-SA esiste una copia dell'applicazione MHP da ditribuire via broadcast, i dati relativi a elenco branche delle prestazioni, elenco prestazioni ed elenco dei presidi eroganti sono attesi da SIL-SP.

1. SIL_SP pubblica un evento CART contenente i dati sopra menzionati, CS-DTT-SA è il sottoscrittore di tale evento e come tale riceve i dati che sono pubblicati in formato XML;

2. CS-DTT-SA recupera i dati dal documento XML e li serializza in maniera opportuna per l'applicazione MHP;

3. CS-DTT-SA pubblica su CART l'intera applicazione o solo i dati relativi all'applicazione in funzione del fatto che si sia nel caso di Pubblicazione o di Aggiornamento secondo le specifiche descritte in [1]. L'applicazione o i dati vengono pubblicati come archivio e allegati al messaggio CART;

4. CS-DTT, che funge da sottoscrittore dell'evento al punto 3, recupera l'intera applicazione o i dati di aggiornamento ad essa destinati e li inoltra ai broadcaster accreditati;

5. I broadcaster diffondono l'applicazione che può essere mandata in esecuzione da UF su di un Set Top Box;


4. Prototipo
============
Al fine di esemplificare il funzionamento del sistema appena descritto è stato realizzato un prototipo che, pur non utilizzando la comunicazione attraverso l'infrastruttura CART, permette una valutazione del funzionamento del servizio almeno per quanto riguarda il canale DTT-MHP.

L'applicazione destinata all'Utilizzatore Finale è, in questo caso, un'applicazione MHP che viene messa in broadcast da un'emittente televisiva e che è in grado di dialogare tramite modem 56k con SIL_SP.
Essa viene distribuita comprensiva delle informazioni necessarie a costruire un menu gerarchico come descritto nel punto 1 del caso d'uso n°1 presentato. L'aggiornamento delle informazioni necessarie alla costruzione del menu gerarchico viene operato da SIL_SP stesso tramite un'applicazione preposta.
L'Utilizzatore Finale può quindi navigare i menu di selezione delle prestazioni sanitarie aggiornate come descritto nel caso d'uso n°1.
Una volta scelta la prestazione sanitaria e, contestualmente, tutti i paramentri descritti nel paragrafo 3, l'applicazione MHP inoltra via HTTPS la richiesta a SIL_SP di un elenco di disponibilità.
SIL_SP risponde con un documento di testo come descritto precedentemente.
Il documento di testo viene restituito via modem all'applicazione MHP e utilizzato per completare i passi sopra descritti.

Nell'implementazione prototipale qui descritta non viene utilizzato il proxy di CS-DTT per inoltrare le chiamate via canale di ritorno al servizio di prenotazione. 
L'URL di richiesta delle disponibilità assume in questo caso la forma:

https://"server":"porta"/"sottocartella"/"servlet"?nome=vnome&cognome=vcognome&cf=vcf&tel=vtel&prz=vprz&pre=vpre&unita=vunita&fascia=vfascia

mentre l'URL di richiesta di prenotazione di una certa disponibilità assume la forma:

https://"server":"porta"/"sottocartella"/"servlet"?dispo=vdispo

I file di testo delle risposte del servizio di prenotazione sono formattati come descritto nel caso d'uso n°1.


5. Bibliografia
===============
1. RFC n°15 “Digitale Terrestre” - Centro Servizi Regionale per il Digitale Terrestre del 10/10/2006.

